Business method for secure installation of a credit authorization key on a remote tcpa compliant system

ABSTRACT

Abstract of the Disclosure A business method employing hardware complaint to the Trusted Computing Platform  Alliance (TCPA) Specification is implemented to allow a credit card company to remotely install a credit card private key into a TCPA module to create a Trusted Platform Module (TPM).  More specifically, when a credit worthy user applies for a credit card,  the user will send the credit card company a public portion of a &#34;non-migratable storage key,&#34; which is accredited a TPM endorsed by a Certification Authority.   The credit card company will create its own public/private key pair according to the TCPA Specification, to create a TCPA header, and wrap the full structure by encrypting it with the public portion of the TCPA non-migratable storage key.  The credit card company then sends by email the encrypted bundle with a certificate for it, and sends a corresponding pass phrase by regular mail.

Cross Reference to Related Applications

[0001] This application is a continuation-in-part of application SerialNo. 09/851956 entitled System and Method for Installing a Remote CreditCard Authorization on a System with a TCPA Complaint Chipset.

Technical Field

[0002] The present invention relates in general to data processingsystems, and in particular, to enabling secure communications over dataprocessing networks.

Background Information

[0003] The Internet provides a new arena for electronic commerce inwhich credit card companies are very interested. Quite naturally, since"commerce" is a necessary part of e-commerce, it stands to note thatproviding for the transfer of funds and credit during e-commercetransactions bodes well for those credit card companies that cansecurely provide for such transactions. One of the main concerns thatcontinues with respect to e-commerce is the lack of trust that theconsuming public has in the security of such transactions to protecttheir credit card and banking accounts.

[0004] One current method for obtaining a credit card from a credit cardcompany on- line is for the user to fill out a credit card applicationat the credit card company's website, and then if approved, the creditcard company will send a physical credit card to the user who can thenactivate the credit card by calling a toll-free number from the user'shome phone. However, credit card theft is abundant, and according tosome reports, accounts for half of the monetary loss of the credit cardcompanies.

[0005] To eliminate the need for a physical credit card, another priorart method is to send to the user a smartcard for use in on-linetransactions. However, the problem with a smartcard is one of expense,since use of a smartcard requires a smartcard reader to be installed onthe user's computer.

[0006] As a result, there is a need in the art for a less expensive butreliable and secure process for enabling users to obtain a credit cardauthorization that they can use on their computer for facilitatingpurchases over the Internet.

Brief Summary of the Invention

[0007] The present invention makes use of the TCPA (Trusted ComputingPlatform Alliance) Specification to allow a company to remotely installan authorization private key into a TCPA module in a way that thecompany can be assured it is going to a trusted TPM (Trusted PlatformModule). While the invention is not limited to credit card companies,the most detailed examples shown are for credit card companies. In thespecific case of a credit card company, when a user applies for a creditcard, the credit card company will first determine if the person iscredit worthy. Assuming they are, then the user will send the creditcard company a public portion of a "non-migratable storage key," whichis accredited a TPM which is in turn endorsed by a CertificationAuthority (CA). The private portion of the "non-migratable storage key"is known to be a key that was created inside the TPM, and cannot beexported from the TPM. The credit card company will now create its ownpublic/private key pair according to the TCPA Specification, usingwhatever size key it desires, create a TCPA header, and wrap the fullstructure by encrypting it with the public portion of the TCPAnon-migratable storage key. The credit card company will then send byemail to the person the encrypted bundle and a certificate for it, andvia "snail mail," a pass phrase that is hashed to provide usage of theencrypted bundle on the person's system. The present invention providesfor an interaction between the credit card company and the user in a wayso that the credit card company is assured that a private key used by auser is used to the same degree that the user uses a physical creditcard. That is, an embodiment of the present invention establishes asimilar level of trust for a credit card authorization over the Internetas presently exists for transactions using physical credit cards instores.

[0008] In one alternative embodiment of the present invention, thecredit card company can be its own certification authority.

[0009] An advantage of the present invention is that only one usercomputer can use the encrypted bundle sent by the credit card company,which will reduce the amount of fraud by use of credit cards ine-commerce transactions. Another advantage of the present invention isthat the certificate can easily be checked against the credit cardcompany's database for revocation. Using this type of signature insteadof a credit card number precludes someone from charging a credit cardmultiple times, and also precludes someone keeping a database of creditcard numbers to be exposed to a hacker accessing such numbers.

[0010] The foregoing has outlined rather broadly the features andtechnical advantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention.

Brief Description of the Several Views of the Drawings

[0011] For a more complete understanding of the present invention, andthe advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings, inwhich:

[0012]FIGURE 1 illustrates a data processing system configured inaccordance with an embodiment of the present invention;

[0013]FIGURE 2 illustrates a flow diagram configured in accordance withan embodiment of present invention; and

[0014]FIGURE 3 illustrates a network configured in accordance with anembodiment of present invention.

[0015]FIGURE 4 illustrates a business method in accordance with anembodiment of the present invention.

Detailed Description of the Invention

[0016] In the following description, numerous specific details are setforth such as encryption methods or key lengths, etc. to provide athorough understanding of the present invention. However, it will beobvious to those skilled in the art that the present invention may bepracticed without such specific details. In other instances, well-knowncircuits have been shown in block diagram form in order not to obscurethe present invention in unnecessary detail. For the most part, detailsconcerning timing considerations and the like have been omitted in asmuch as such details are not necessary to obtain a completeunderstanding of the present invention and are within the skills ofpersons of ordinary skill in the relevant art.

[0017] Referring to FIGURE 3, there is illustrated a configuration of anetwork 300 in accordance with the present invention where a user(customer) computer 301 applies for a credit card authorization from acredit card company server 302 over the Internet 303.

[0018] Referring to FIGURE 1, there is illustrated exemplary dataprocessing system 113 configured in accordance with the presentinvention, whereby system 113 could be used for the user computer 301,the credit card company server 302, and any and all servers used in theInternet 303 to communicate data between computer 301 and server 302.

[0019] The system 113 has a central processing unit (CPU) 110, which iscoupled to various other components by system bus 112. Read-only memory("ROM") 116 is coupled to the system bus 112 and includes a basicinput/output system ("BIOS") that controls certain basic functions ofthe data processing system 113. Random access memory ("RAM") 114, I/Oadapter 118, and communications adapter 134 are also coupled to thesystem bus 112. I/O adapter 118 may be a small computer system interface("SCSI") adapter that communicates with a disk storage device 120.Communications adapter 134 interconnects bus 112 with an outside network160 (e.g., the Internet 303) enabling the data processing system tocommunicate with other such systems. Input/Output devices are alsoconnected to system bus 112 via user interface adapter 122 and displayadapter 136. Keyboard 124 and mouse 126 are all interconnected to bus112 via user interface adapter 122. Display monitor 138 is connected tosystem bus 112 by display adapter 136. In this manner, a user is capableof inputting to the system 113 throughout the keyboard 124 or mouse 126and receiving output from the system via display 138.

[0020] Implementations of the invention include implementations as acomputer system programmed to execute the method or methods describedherein, and as a computer program product. According to the computersystem implementation, sets of instructions for executing the method ormethods may be resident in the random access memory 114 of one or morecomputer systems configured generally as described above. Until requiredby the computer system, the set of instructions may be stored as acomputer program product in another computer memory, for example, indisk drive 120 (which may include a removable memory such as an opticaldisk or floppy disk for eventual use in the disk drive 120). Further,the computer program product can also be stored at another computer andtransmitted when desired to the user's workstation by a network or by anexternal network such as the Internet 303. One skilled in the art wouldappreciate that the physical storage of the sets of instructionsphysically changes the medium upon which it is stored so that the mediumcarries computer readable information. The change may be electrical,magnetic, chemical, biological, or some other physical change. While itis convenient to describe the invention in terms of instructions,symbols, characters, or the like, the reader should remember that all ofthese and similar terms should be associated with the appropriatephysical elements.

[0021] Note that the invention may describe terms such as comparing,validating, selecting, identifying, or other terms that could beassociated with a human operator. However, for at least a number of theoperations described herein which form part of at least one of theembodiments, no action by a human operator is desirable. The operationsdescribed are, in large part, machine operations processing electricalsignals to generate other electrical signals.

[0022] Referring to FIGURE 2, there is illustrated a flow diagram of aprocess configured in accordance with an embodiment of the presentinvention where a potential credit card customer desires to receive anembedded credit card authorization within the customer's computer system301. In step 201, the customer will create a TPM identity per the TCPASpecification and obtain a certificate for it. The TCPA Specification ispublished at www.trustedpc.org/home/home.htm, as Version 1.1b, which ishereby incorporated by reference herein. When a TPM is manufactured, itsown endorsement key is generated and placed into nonvolatile memoryinside the TPM chip. Only the public portion of that endorsement key,P1, is ever released from the chip, and is released to the manufacturer.The manufacturer of the TPM signs a certificate, C1, that goes alongwith the TPM. Alternatively, the certificate, C1, can be retrieved by auser over the Internet from the manufacturer. This certificate, C1, istied to the public portion of the endorsement key, P1, that determinesthat the public key is the endorsement key of this particular TPM. Thisendorsement key, P1, is used for decrypting.

[0023] As noted above, a TPM identity is created in step 201, which is aspecial kind of private key. A TPM identity can be created by thecustomer, such as with a DOS command, and the TPM identity is the publicportion of a public/private key pair.

[0024] The public key, P2, of the TPM identity and the certificate, C1,tied to the public portion of the endorsement key, P1, are then sentover the Internet to a Certificate Authority (CA). This may beauthorized by the user as a result of a user command. The CA checks theaccuracy of the certificate, C1, signed by the manufacturer. The CA canperform this check by looking in a database at the manufacturer'swebsite. The CA then makes a certificate, C2, for the TPM identity, P2,and encrypts the certificate, C2, and bundles it with the public key,P2, of the TPM identity sent by the customer. This second bundle is thenencrypted with the public endorsement key, P1, of the TPM.

[0025] The second bundle is then returned to the customer by the CA,which is then decrypted by the TPM with the private portion of theendorsement key, P3. This protects from unauthorized requests forcertificates from a CA. The TPM will then decrypt the first bundle withthe private key, P4, of its TPM identity to obtain the certificate, C2,issued by the CA. The result is a TPM identity that has been signed by aCA.

[0026] In step 202, the customer with create a non-migratable key. TheTCPA Specification has two types of keys used to store other keys. Thefirst type is "migratable," and the owner of the system is able to movesuch keys to other systems, as long as the owner knows the correctauthorization data. It is possible to move such keys to insecure systemsthis way, and hence, migratable keys can be exposed by the owner of thesystem. This may or may not be a problem to a credit card company.Currently, a consumer exposes his key to a seller every time he showshis credit card, so currently, there is no requirement that keys be keptout of the hands of the customer. "Non-migratable" keys are locked tothe hardware in a way that they cannot be cloned or migrated to anothersystem even by the owner. They are thus inherently more secure.

[0027] In one alternative embodiment of step 202, the customer creates anon-migratable storage key, K1, that may be a 2048-bit RSA key. Astorage key is used for encrypting other keys so that the TPM can readthem (i.e., a storage key decrypts items into the TPM). To create anon-migratable storage key, the customer may use the CreateWrapKeyfunction of the TCPA Specification. There may also be a piece ofsoftware that does this for the user in a user-friendly way. Thecustomer will then decide if the key, K1, will require authorization ornot, and what that authorization would be. When the key is created, thecustomer decides if he wants to require authorization for use and if so,what pass phrase to use to provide the authorization. Software can beused to require authorization using some other type of means instead ofa pass phrase, such as through the use of biometrics. The customer alsodecides what parent will be used for storing this key (the SRK (storageroot key) is available). The parent key is a key used to store anotherkey. The key stored is called a child, while the key used to do thestoring is called the parent. In particular, if there are two key pairs,Private One, Public One and Private Two, Public Two, if Private Two isencrypted with Public One, then the first key pair would be referred toas the parent and the second key pair the child. Further, there is onekey that is guaranteed to always be loaded inside the chip. It is calledthe storage root key, and it is an ancestor of every other key the chipcan use. To load a key into the chip, it needs to have its parent'sprivate key already loaded in the chip (so the chip can decrypt it). Ifthe SRK is the great grandparent of a key, first one would need to loadthe grandparent of a key in the chip, then the parent of the key intothe chip, and finally the key itself into the chip. This structure,called a daisy chain, is used to allow a TCPM chip to "store" anunlimited number of keys. The customer will then execute aTPM_CreateWrapKey command, with required parameters indicating the keyproduced will be a storage key. The customer then signs thenon-migratable storage key, K1, with the TPM identity key, P2, creatinga certificate, C3, for that non-migratable storage key.

[0028] In another alternative embodiment of step 202, the customercreates a non-migratable signing key, K2, with the TPM_CreateWrapKeycommand, wherein the key may be a 2048-bit RSA key. Signing keys can beused by the TPM to sign the hash of a message (i.e., encrypt the hash ofa message). The customer decides if this signing key, K2, will requireauthorization or not, and what that authorization will be. The customerdecides what parent will be used for storing this key (the SRK isavailable). The customer executes the TPM_CreateWrapKey command, withrequired parameters indicating the key, K2, will be a signing key. Andthen, the customer signs the non-migratable signing key, K2, with theTPM identity key, P2, creating a certificate, C4, for that key, K2.

[0029] In step 203, the customer contacts a credit card company over theInternet by browsing the credit card company's website. In step 204, thecustomer applies for a credit card authorization at the credit cardcompany website by entering into a secure section of that website tofill out an application form. This implies a Secure Sockets Layer (SSL)to prove to the customer that the information he is giving the creditcard company is not snoopable, and a certificate to prove to thecustomer he is indeed at the credit card company's web site. SSL is ameans of creating encrypted communication between a user and a web sitefor entering a credit card without snoopers being able to access thenumber. The customer fills out the application form with his name,address and whatever other information the credit card company requiresto determine whether the customer is credit worthy.

[0030] In step 205, under the first alternative embodiment describedabove where the customer creates a non-migratable storage key, K1, thecustomer will provide to the credit card company the non-migratablepublic portion of the storage key, K1, the certificate, C3, by the TPMidentity that the RSA storage key is a non-migratable TPM key, thecertificate, C2, from the CA that the TPM identity is indeed a TPMidentity, and a pass phrase the customer would like to use forauthorizing use of the requested credit card authorization. It is atthis point that the credit card company can evaluate the requested passphrase and turn it down if it appears to be too trivial.

[0031] If the customer had created a non-migratable signing key, K2,under the second alternative embodiment described above with respect tostep 202, the customer will provide to credit card company in step 205that non-migratable public portion of that signing key, K2, thecertificate, C4, by the TPM identity that the signing key is anon-migratable TPM key, and the certificate, C2, from the CA that theTPM identity is indeed a TPM identity. In this embodiment, the passphrase is chosen by the user, but is never provided to the credit cardcompany.

[0032] In step 206, the credit card company determines the creditworthiness of the customer, and assuming the customer is credit worthy,the credit card company then checks the TPM identity certificate, C2, tosee the level of security inherent in the TPM system to determine ifthat is sufficient to proceed. The credit card company may also check tosee if the TPM identity certificate, C2, has been revoked by the CA thatissued it.

[0033] In step 207, the credit card company creates a public/private keypair, P5, and a certificate, C5, to send to the customer. If thecustomer had previously sent a non-migratable storage key, K1, under thefirst alternative discussed above, then the credit card company willperform the following procedure. The credit card company will create thepublic/private key pair, P5, which may be a 2048-bit RSA key. If thecredit card company wants to use a different kind of key, the TPMidentity certificate, C2, will have to be checked to see if the TPMsupports such a different kind of key. The credit card company will thencreate a header for the key, P5, using the format defined in the TCPASpecification, which is hereby incorporated by reference herein. In onealternative embodiment of this step, the header is created using theSHA-1 hash of the pass phrase selected by the customer, a migration passphrase the credit card company generates, and creating a TCPA key bundlewrapping the key, P5, in the public key, K1, the customer gave thecredit card company. In another alternative embodiment, the credit cardcompany can create the header by using its own TCPA chip by commandingit to create a migratable key using the requisite pass phrases andchoosing its own storage key (of any sort) for its own TPM, and thenmigrating that key to the customer's TPM public key, K1. If the creditcard company performs this process, it must pass the end user the bundleand the random number that is used for this transition.

[0034] The credit card company then creates its own certificate, C5, forthe public key, P5, it created. In one alternative embodiment of thissubstep, the credit card company mails (traditional mail services) adiskette with the bundle stored on it to the verified address of thecustomer. In another alternative embodiment of this subset, the creditcard company emails or mails the bundle to the customer (thus allowingverification of address) and either mails the random number to thecustomer with the bundle, or mails the random number to the end userseparately, or mails the end user a 1-800 telephone number to call inorder to get the random number (thus allowing verification of telephonenumber).

[0035] If the customer had sent a non-migratable public portion of asigning key, K2, then the credit card company certifies the public keyit has been sent and sends the certificate to the mailing address(proving verification of address) on a diskette. If the credit cardcompany also wants to verify the telephone number, the certificate canbe encrypted, for example X-ored with the SHA-1 hash of a pass phrasewhich is delivered over the phone.

[0036] At the end of this process, in step 208, the customer now has aprivate key pair which can only be used on the customer's computersystem using a pass phrase the customer was allowed to choose, and whichhas a certificate of the credit card company. The credit card companycan revoke the certificate whenever it wants.

[0037] An advantage of the first alternative described above where anon-migratable storage key is utilized, the credit card company can usethe same key on multiple systems belonging to the customer, by simplyre-wrapping the key with multiple storage keys of the customer. This isnot possible with the second alternative where a signing key is created,unless the credit card company is willing to use migratable signingkeys.

[0038] An advantage of the second alternative discussed above where thecustomer creates a non-migratable public portion of a signing key, thecredit card company never receives the pass phrase from the customerused to authorize use of the key on the customer's system.

[0039] In an alternative embodiment of the present invention, a creditcard company can perform a self-certification for a receivednon-migratable storage key. The customer of the system takes thecertificate, C1, that was signed by the manufacturer of the system. Thisincludes information regarding the security level the system wasdesigned to as well as a certificate from the manufacturer of the TPMchip itself and a copy of P1, the endorsement public key from the TPM.The customer also asks the TPM (through a standard command) to generatea "TPM identity," a 2048-bit RSA signing key. The TPM returns the publicportion of that key, P2. The customer takes P2 and the Certificate, C1,for the system and sends them to the credit card manufacturer. Thecredit card company verifies the certificate using the public keys ofthe manufacturer of both the TPM and the system and then provides acertificate, C6, for P2. However, the credit card company encrypts thiscertificate, C6, using P1 (as per the TCPA Specification). Thisencrypted certificate is sent back to the customer of the system. Thecustomer sends the encrypted certificate, C6, to his TPM, (reloading theTPM identity key if necessary). The TPM checks the certificate againstthe identity key making certain that they match. If they do, the TPMexports enough information to decrypt the credit card company'scertificate, C6, for that key.

[0040] The customer then requests his TPM to produce a non-migratablestorage key (or non-migratable signing key depending on whichalternative he is taking). The TPM returns the public portion of thekey. The customer then requests the TPM to sign the public portion ofthe non-migratable key in the last step with his identity. The TPM doesthis, providing an identity certificate that it is a non-migratable(storage or signing) key. The customer then sends the public portion ofthe non-migratable key, its identity-based certificate, and the creditcard company certificate, C6, for the identity, back to the credit cardcompany, which can then use its own certification of the quality of thenon-migratable key.

[0041] An additional embodiment will now be described in which a remoteentity can install a private key on a remote user's Trusted PlatformModule (TPM) associated with the remote user's computer system. Theembodiment provides for secure usage of the key while retaining thekey's transfer within the control of the remote entity.

[0042] This embodiment provides a method for conducting business bywhich a company, such as a credit card company, creates a privatesignature key (which would represent a credit card in the example whichfollows) and transfers the key to an end user in a way that (i)preserves security, (ii) preserves control over the locale or localeswhere the key is to be used - for example, restricting the locale to theremote entity's locale (so that the remote entity can restrict the usageof the key to secure environments), and (iii) preserve control over theusage of the key - for example, restricting usage to the end user (sothat only the designated end user can use the credit card). In theexample which follows, a credit card company deploying a credit cardproduct is shown as employing the method of doing business of thisembodiment. The end product need not be a credit card, it can be a debitcard or a general bank card used for all types of transactions. Theexample given below is not meant to be limiting in any way. For example,and not by way of limitation, the company can be a trust managementcompany and the product can be a trust or will where authentication isgiven for power of attorney. The company can be an cable televisioncompany and the product a cable subscription service such as pay perview. The company may be an insurance provider and the product a medicalbenefits dispersion. In short, a provider benefits by the teachings ofthis embodiment for secure authentication for anything having good andvaluable consideration.

[0043] Referring now to Fig. 4, the transactions or steps of thisembodiment of a method of doing business are shown between an end user401 and a credit card company 402. In step 404, the credit card company402 receives a credit card private key request from an end user 401 whenend user 401 applies for a credit card private key. In step 405, thecredit card company 402 checks that the Applicant is qualified toreceive the credit card key. This checking step 405 can be for examplethe checking of the end user's 401 credit worthiness. In still anotherembodiment of step 405, and not by way of limitation, the checking step405 can be to check whether the end user has an existing account etc.Upon qualification, in step 407, the credit card company 402 requests ofthe end user's 401 Trusted Platform Module (TPM) associated with the enduser's 401 computer system a secure non-migratable storage key. Next, instep 408, the credit card company 402 receives the secure non-migratablestorage key generated by end user's 401 Trusted Platform Module. Tocreate a non-migratable storage key, the customer may use theCreateWrapKey function of the TCPA Specification as describedhereinabove. The secure non-migratable storage key is received alongwith any of the following:

(A) a certificate from a Certificate Authority (CA) that states that thestorage key is secure and non-migratable;

(B) a certificate from a TPM identity key which states that the storagekey is secure and non-migratable along with a certificate from aCertificate Authority which states that the TPM identity is a TPMidentity; or

(C) an endorsement key certificate from a Certificate Authority , and acertificate from a TPM identity key which states that the storage key issecure and non-migratable along with a certificate from a CertificateAuthority which states that the TPM identity is a TPM identity.

[0044] Steps 409 and 410 are optionally utilized when it is the items of(C) which are received. In this case, the credit card company 402creates a certificate for the TPM identity key, encrypts the certificateas per the TCPA specification / TPM specification - as in for examplekey1, and sends key1 back to the user encrypted in a blob containing thepublic identity key and encrypted with the public endorsement key. Whensteps 409 and 410 are required, processing continues with step 410. Instep 410, a decrypted identity certificate is received by the creditcard company 402. This decrypted identity certificate is generated as aresult of the end user 401 utilizing the TPM associated with end user's401 computer system to decrypt the TPM identity key certificate; which,in turn, utilizes the provided endorsement private key to decrypt thekey used to decrypt the certificate - but only if the TPM identity keymatches the identity key generated by that TPM.

[0045] Upon verification that the storage key is a TPM non-migratablekey, and hence secure, the credit card company 402 creates a pair ofpublic credit card private keys, and

(A) keeps the first copy secure for later migration as necessary, alongwith the public portion of the storage key, and

(B) continues with the step shown at 411. In step 411, the credit cardcompany 402 wraps the second copy with the public storage key as per theTPM specification, and sends the requested credit card private key backto the user.

[0046] Upon receipt of the credit card private key per step 411, themethod continues with the final step 412. In step 412, the user 401waits to receive the code word necessary to use the key via a securechannel to the user. The secure channel can be:

(1) Via phone with ANI verifying the calling party;

(2) Via the mail, as credit card numbers / PINs are currently done; and

(3) Via the mail and ANI, to verify the mail was received by theintended recipient.

[0047] Additional steps can be securely taken as necessary. In theexample which follows, a virtual private network (VPN) is utilized toestablish a secure connection between the end user 401 and the creditcard company 402. Details concerning VPNs are well known in the art andare omitted so as to not obfuscate the present disclosure in unnecessarydetail. In this example, if the end user 401 desires to change his orher password or PIN code, this can be done securely as follows:

A VPN is setup between the credit card company 402 and the end user 401,using the private key of the user to identify the credit card company402;

The user 401 asks that the private key be re-wrapped using the preferredpassword / PIN;

The credit card company 402 re-wraps the key with the public portion ofthe storage key, with the new password / PIN contained therein.

[0048] Although the present invention and its advantages have beendescribed in detail, it should be understood that various changes,substitutions and alterations can be made herein without departing fromthe spirit and scope of the invention as defined by the appended claims.

What is Claimed is: A business method comprising the steps of:
 1. (a)receiving a request for a private key over a first network and from aremote device having a TPM (Trusted Platform Module) associated with anend user entity; (b) verifying the worthiness of the received request asrepresented by a TPM identity of the remote device; (c) requesting andreceiving over the first network a non-migratable storage key from theTPM of the remote device when the received request is deemed worthy asdetermined by said verifying step (b); (d) receiving a certificate froma Certificate Authority which certifies the non-migratable storage keyas both secure and non-migratable; and (e) wrapping an encrypted privatekey with the non-migratable storage key as per the TCPA specification,and sending the encrypted private key to the remote device over thefirst network.
 2. The method ofclaim 1 further comprising the step ofsending over a second network a pass code which facilitates thedecryption of the encrypted private key, wherein the second network is anetwork selected from the group consisting of a network which isphysically different than the first network, a network which islogically different than the first network, and a network which isphysically and logically different than the first network.
 3. The methodofclaim 1 further comprising the step of sending over regular mail apass code which facilitates the decryption of the encrypted private key.A business method comprising the steps of:
 4. (a) receiving a requestfor a private key over a first network and from a remote device having aTPM (Trusted Platform Module) associated with an end user entity; (b)verifying the worthiness of the received request as represented by a TPMidentity of the remote device; (c) requesting and receiving over thefirst network a non-migratable storage key from the TPM of the remotedevice when the received request is deemed worthy as determined by saidverifying step (b); (d) receiving a certificate from a TPM identitycertifying the non-migratable storage key as both secure andnon-migratable, and further receiving a certificate from a CertificateAuthority certifying that the TPM identity is a TPM identity; and (e)wrapping an encrypted private key with the non-migratable storage key asper the TCPA specification, and sending the encrypted private key to theremote device over the first network.
 5. The method ofclaim 4 furthercomprising the step of sending over a second network a pass code whichfacilitates the decryption of the encrypted private key, wherein thesecond network is a network selected from the group consisting of anetwork which is physically different than the first network, a networkwhich is logically different than the first network, and a network whichis physically and logically different than the first network.
 6. Themethod ofclaim 4 further comprising the step of sending over regularmail a pass code which facilitates the decryption of the encryptedprivate key. A business method comprising the steps of:
 7. (a) receivinga request for a private key over a first network and from a remotedevice having a TPM (Trusted Platform Module) associated with an enduser entity; (b) verifying the worthiness of the received request asrepresented by a TPM identity of the remote device; (c) requesting andreceiving over the first network a non-migratable storage key from theTPM of the remote device when the received request is deemed worthy asdetermined by said verifying step (b); (d) receiving an endorsement keycertificate from a Certificate Authority, and further receiving acertificate from a TPM identity certifying the non-migratable storagekey as both secure and non-migratable, and further receiving acertificate from a Certificate Authority certifying that the TPMidentity is a TPM identity; (e) originating a certificate for the TPMidentity and encrypting the certificate as per the TCPA specificationand sending the encrypted certificate to the remote device wherein theencryption is based on the endorsement key certificate; (f) receiving adecrypted identity certificate which is decrypted by the remote devicewhen the TPM identity certificate as originated in said originating step(e) matches the TPM identity of the remote device; and (g) wrapping anencrypted private key with the non-migratable storage key as per theTCPA specification, and sending the encrypted private key to the remotedevice over the first network.
 8. The method ofclaim 7 furthercomprising the step of sending over a second network a pass code whichfacilitates the decryption of the encrypted private key, wherein thesecond network is a network selected from the group consisting of anetwork which is physically different than the first network, a networkwhich is logically different than the first network, and a network whichis physically and logically different than the first network.
 9. Themethod ofclaim 7 further comprising the step of sending over regularmail a pass code which facilitates the decryption of the encryptedprivate key. A program product comprising: a computer usable mediumhaving computer readable program code embodied therein, the computerreadable program code in said program product being effective inexecuting the steps of:
 10. (a) receiving a request for a private keyover a first network and from a remote device having a TPM (TrustedPlatform Module) associated with an end user entity; (b) verifying theworthiness of the received request as represented by a TPM identity ofthe remote device; (c) requesting and receiving over the first network anon-migratable storage key from the TPM of the remote device when thereceived request is deemed worthy as determined by said verifying step(b); (d) receiving a certificate from a Certificate Authority whichcertifies the non-migratable storage key as both secure andnon-migratable; and (e) wrapping an encrypted private key with thenon-migratable storage key as per the TCPA specification, and sendingthe encrypted private key to the remote device over the first network.11. The program product ofclaim 10 further comprising the step ofsending over a second network a pass code which facilitates thedecryption of the encrypted private key, wherein the second network is anetwork selected from the group consisting of a network which isphysically different than the first network, a network which islogically different than the first network, and a network which isphysically and logically different than the first network.
 12. Theprogram product ofclaim 10 further comprising the step of sending overregular mail a pass code which facilitates the decryption of theencrypted private key. A program product comprising: a computer usablemedium having computer readable program code embodied therein, thecomputer readable program code in said program product being effectivein executing the steps of:
 13. (a) receiving a request for a private keyover a first network and from a remote device having a TPM (TrustedPlatform Module) associated with an end user entity; (b) verifying theworthiness of the received request as represented by a TPM identity ofthe remote device; (c) requesting and receiving over the first network anon-migratable storage key from the TPM of the remote device when thereceived request is deemed worthy as determined by said verifying step(b); (d) receiving a certificate from a TPM identity certifying thenon-migratable storage key as both secure and non-migratable, andfurther receiving a certificate from a Certificate Authority certifyingthat the TPM identity is a TPM identity; and (e) wrapping an encryptedprivate key with the non-migratable storage key as per the TCPAspecification, and sending the encrypted private key to the remotedevice over the first network.
 14. The program product ofclaim 13further comprising the step of sending over a second network a pass codewhich facilitates the decryption of the encrypted private key, whereinthe second network is a network selected from the group consisting of anetwork which is physically different than the first network, a networkwhich is logically different than the first network, and a network whichis physically and logically different than the first network.
 15. Theprogram product ofclaim 13 further comprising the step of sending overregular mail a pass code which facilitates the decryption of theencrypted private key. A program product comprising: a computer usablemedium having computer readable program code embodied therein, thecomputer readable program code in said program product being effectivein executing the steps of:
 16. (a) receiving a request for a private keyover a first network and from a remote device having a TPM (TrustedPlatform Module) associated with an end user entity; (b) verifying theworthiness of the received request as represented by a TPM identity ofthe remote device; (c) requesting and receiving over the first network anon-migratable storage key from the TPM of the remote device when thereceived request is deemed worthy as determined by said verifying step(b); (d) receiving an endorsement key certificate from a CertificateAuthority, and further receiving a certificate from a TPM identitycertifying the non-migratable storage key as both secure andnon-migratable, and further receiving a certificate from a CertificateAuthority certifying that the TPM identity is a TPM identity; (e)originating a certificate for the TPM identity and encrypting thecertificate as per the TCPA specification and sending the encryptedcertificate to the remote device wherein the encryption is based on theendorsement key certificate; (f) receiving a decrypted identitycertificate which is decrypted by the remote device when the TPMidentity certificate as originated in said originating step (e) matchesthe TPM identity of the remote device; and (g) wrapping an encryptedprivate key with the non-migratable storage key as per the TCPAspecification, and sending the encrypted private key to the remotedevice over the first network.
 17. The program product ofclaim 16further comprising the step of sending over a second network a pass codewhich facilitates the decryption of the encrypted private key, whereinthe second network is a network selected from the group consisting of anetwork which is physically different than the first network, a networkwhich is logically different than the first network, and a network whichis physically and logically different than the first network.
 18. Theprogram product ofclaim 16 further comprising the step of sending overregular mail a pass code which facilitates the decryption of theencrypted private key.